Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-141

Text File | 1996-03-23 | 116.3 KB | 3,131 lines | [TEXT/R*ch]

C.S.M.P. Digest             Wed, 20 Mar 96       Volume 3 : Issue 141

Today's Topics:

        Async. Driver IO Questions - Need Help
        Code For Changing Monitor Resolutions?
        Do all functions -procedures allocate memory?
        Drawing behind TE fields
        How Often Do I Lock a Handle?
        Limiting the mouse region
        MOVE 16
        Making sense of memory management
        More than 255 chars with GetDialogItemText() ???
        Multitasking w- WaitNextEvent()???
        Program to Program Communication (PPCInform, PPCStart)
        Q: The OSErr type, and unreserved values....
        QD3D and Textures...
        System 7 PopUp CDEF Shares MenuHandles?
        Where can I get a CustomGetFolder that works?
        Wrapping Pictures Around Closed QD3D Surfaces
        [Q] Building Popup-menus at runtime



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Ram Rajadhyaksha)
Subject: Async. Driver IO Questions - Need Help
Date: Sat, 17 Feb 1996 02:33:09 -0500
Organization: The Ohio State University

I'm back. :-) Anyways, I'm having a minor problem with a program that does
a lot of intensive asynchronous IO with a SCSI driver. Occassionally I try
to queue a read request and it dies with a result code of -36, which (oh
my god!) happens to be: IO error. Real helpful.

Anyways, this only happens with VM turned on so I'm wondering if it is a
problem with not properly locking my IO buffers. My current method, as
recommended by another engineer, is to call LockMemoryContiguous and if
that fails, call LockMemory. Does anyone have any clue about what I might
be doing wrong? Is there a way I should reserve my buffers so they won't
be affected by VM?

The second question is somewhat of a stupid one. If I decide to recompile
this program for nativeness, how is my ioCompletion routine supposed to
get passed a paramblock? On 68k, it's a simple deal of the device manager
passing the pointer in register A0.

Any help is greatly appreciated. Please email your responses since I don't
get a chance to frequent this group often.

Thanks!

--Ram Rajadhyaksha

+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Sun, 18 Feb 1996 02:27:03 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article
<[e-mail]>,
[e-mail] (Ram Rajadhyaksha) wrote:

>I'm back. :-) Anyways, I'm having a minor problem with a program that does
>a lot of intensive asynchronous IO with a SCSI driver. Occassionally I try
>to queue a read request and it dies with a result code of -36, which (oh
>my god!) happens to be: IO error. Real helpful.
>
>Anyways, this only happens with VM turned on so I'm wondering if it is a
>problem with not properly locking my IO buffers. My current method, as
>recommended by another engineer, is to call LockMemoryContiguous and if
>that fails, call LockMemory. Does anyone have any clue about what I might
>be doing wrong? Is there a way I should reserve my buffers so they won't
>be affected by VM?

I'm fairly certain that the OS automatically holds the i/o buffer in
physical memory via HoldMemory for Read and Write calls when VM is on, so
you shouldn't need to do this yourself.  Have you tried testing with a
different SCSI driver to see if there is possible a problem with the
driver itself when VM is on?  Also, you should note the difference between
HoldMemory and LockMemory; the former ensures that the range is held in
physical memory (i.e. not paged to disk), while the latter both holds the
logical address range and also prevents it from moving in physical
memory.  Generally you don't need to call LockMemory unless you're
providing a buffer to a hardware device for DMA, which you're generally
not doing when you issue read/write calls to a device driver.

>The second question is somewhat of a stupid one. If I decide to recompile
>this program for nativeness, how is my ioCompletion routine supposed to
>get passed a paramblock? On 68k, it's a simple deal of the device manager
>passing the pointer in register A0.

Read up on the Mixed Mode Manager in IM: PowerPC System Software.
Basically you declare your i/o completion routine with the parameter block
pointer as a formal parameter and provide a pointer to a routine
descriptor in the ioCompletion field of the parameter block.  When the OS
calls the ioCompletion routine, the Mixed Mode Manager will take care of
moving the 68K A0 parameter into the proper location for your PowerPC
completion routine to access it.  Basically the relevant code would look
something like:

void PowerPCIOCompletionRoutine(ParmBlkPtr pb)
{
    // ...
}

{
    static RoutineDescriptor ioCompletionRD =
BUILD_ROUTINE_DESCRIPTOR(uppIOCompletionProcInfo,
PowerPCIOCompletionRoutine);

    pb.ioParam.ioCompletion = &ioCompletionRD;
    // ...
    err = PBWhateverAsync(&pb);
}

Here I allocate the RoutineDescriptor as a static variable, so that I
don't need to dynamically allocate memory for it (as would be necessary if
the NewIOCompletionProc macro were used.)

Hope this helps.

Chris.

+++++++++++++++++++++++++++

>From [e-mail] (Kluev)
Date: Mon, 19 Feb 96 18:53:14 +0300
Organization: (none)

In article <wysocki-1702961827030001@10.0.2.15>, [e-mail]
(Chris Wysocki) wrote:

>In article
><[e-mail]>,
>[e-mail] (Ram Rajadhyaksha) wrote:
>
>>I'm back. :-) Anyways, I'm having a minor problem with a program that
does
>>a lot of intensive asynchronous IO with a SCSI driver. Occassionally
I try
>>to queue a read request and it dies with a result code of -36, which
(oh
>>my god!) happens to be: IO error. Real helpful.
>>
>>Anyways, this only happens with VM turned on so I'm wondering if it
is a
>>problem with not properly locking my IO buffers. My current method,
as
>>recommended by another engineer, is to call LockMemoryContiguous and
if
>>that fails, call LockMemory. Does anyone have any clue about what I
might
>>be doing wrong? Is there a way I should reserve my buffers so they
won't
>>be affected by VM?
>
>I'm fairly certain that the OS automatically holds the i/o buffer in
>physical memory via HoldMemory for Read and Write calls when VM is on,
so
>you shouldn't need to do this yourself.  Have you tried testing with a

I never understand how it could be done if Read/Write are queued
at time when paging is unsafe. Do you know the answer?

- --------------------------------------------------------------
Michael Kluev                            [e-mail]
Macintosh Programmer                           Physics Grad, MSU
MACsimum Ltd.                                     Moscow, Russia
- --------------------------------------------------------------

+++++++++++++++++++++++++++

>From Bob Gulian <[e-mail]>
Date: Tue, 27 Feb 1996 22:03:49 +0000
Organization: West Coast Online's News Server - Not responsible for content

Ram Rajadhyaksha wrote:
>

> The second question is somewhat of a stupid one. If I decide to recompile
> this program for nativeness, how is my ioCompletion routine supposed to
> get passed a paramblock? On 68k, it's a simple deal of the device manager
> passing the pointer in register A0.
>

In PPC native it's a simple matter of the paramblock ptr being passed
in R3.  In fact, it's even simpler on PPC because an iocompletion
routine typedef with a ParamBlkPtr as an argument is declared in
File.h so all you need to do is declare one callback header for 68k
and one PPC and use #ifdefs.

+++++++++++++++++++++++++++

>From [e-mail] (Kevin McMurtrie)
Date: Wed, 06 Mar 1996 22:02:04 -0800
Organization: hardly any

In article
<[e-mail]>,
[e-mail] (Ram Rajadhyaksha) wrote:

>I'm back. :-) Anyways, I'm having a minor problem with a program that does
>a lot of intensive asynchronous IO with a SCSI driver. Occassionally I try
>to queue a read request and it dies with a result code of -36, which (oh
>my god!) happens to be: IO error. Real helpful.
>
>Anyways, this only happens with VM turned on so I'm wondering if it is a
>problem with not properly locking my IO buffers. My current method, as
>recommended by another engineer, is to call LockMemoryContiguous and if
>that fails, call LockMemory. Does anyone have any clue about what I might
>be doing wrong? Is there a way I should reserve my buffers so they won't
>be affected by VM?

You should call LockMemory on your parameter block and with Status and
Control calls the buffers too.  It is also possible that VM is screwing up
timiming of I/O and causing hardware problems.  I wrote a program to read
audio CDs and error -36 happened so much that I made a thread watch each
I/O request and automaticly retry on errors.

>The second question is somewhat of a stupid one. If I decide to recompile
>this program for nativeness, how is my ioCompletion routine supposed to
>get passed a paramblock? On 68k, it's a simple deal of the device manager
>passing the pointer in register A0.
>
>Any help is greatly appreciated. Please email your responses since I don't
>get a chance to frequent this group often.
>
>Thanks!
>
>--Ram Rajadhyaksha

---------------------------

>From [e-mail] (R. T. Chancellor)
Subject: Code For Changing Monitor Resolutions?
Date: Tue, 20 Feb 1996 20:19:03 -0700
Organization: A Customer of Wavenet

Shockwave Assault has a really nice option that dynamically resets the
monitor's resolution so that you get full screen action. It then resets
the resolution back (upon quitting) so that the Finder does not do that
pesky shuffle of icons to fit on the Desktop.

Does anyone know where I might get a code example of how to do this (in C) ?

+++++++++++++++++++++++++++

>From [e-mail] (NtrlBNkilr)
Date: 21 Feb 1996 19:12:49 -0500
Organization: America Online, Inc. (1-800-827-6364)

If you have access to any of the Inside Macintosh on CD resources....check
out the info on the Display Manager...it can manipulate all aspects of the
display environment.


+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Thu, 22 Feb 1996 03:49:48 -0800
Organization: MacPlay

In article <[e-mail]>,
[e-mail] (R. T. Chancellor) wrote:

>Shockwave Assault has a really nice option that dynamically resets the
>monitor's resolution so that you get full screen action. It then resets
>the resolution back (upon quitting) so that the Finder does not do that
>pesky shuffle of icons to fit on the Desktop.
>
>Does anyone know where I might get a code example of how to do this (in C) ?

Well, you got two real options.

1)  Use the new QuickTime 2.1 call BeginFullScreenMode().  It's a rad
call.  All at once it can:

   o Hide the menubar
   o Change the monitor resolution
   o Create a full-screen window for you
   o Clear the window to a particular RGB color

   Not bad for one function call.

2)  Use the Display Manager routines.  However, doing this requires that
you have to have System 7.5 or newer to make sure that the Display Manager
is present.

L8R
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

+++++++++++++++++++++++++++

>From [e-mail] (David Lawrence)
Date: Fri, 23 Feb 1996 09:11:40 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
[e-mail] (Chris De Salvo) wrote:

> In article <[e-mail]>,
> [e-mail] (R. T. Chancellor) wrote:
>
> >Shockwave Assault has a really nice option that dynamically resets the
> >monitor's resolution so that you get full screen action. It then resets
> >the resolution back (upon quitting) so that the Finder does not do that
> >pesky shuffle of icons to fit on the Desktop.
> >
> >Does anyone know where I might get a code example of how to do this (in C) ?
>
> Well, you got two real options.
>
> 1)  Use the new QuickTime 2.1 call BeginFullScreenMode().  It's a rad
> call.  All at once it can:
>
>    o Hide the menubar
>    o Change the monitor resolution
>    o Create a full-screen window for you
>    o Clear the window to a particular RGB color
>
>    Not bad for one function call.
>
> 2)  Use the Display Manager routines.  However, doing this requires that
> you have to have System 7.5 or newer to make sure that the Display Manager
> is present.



We also included resolution switching in Warcraft.  I'll talk about our
experience with it in a second.  First I want to say that the code is now
available to easily switch resolutions, so I hope that every game from now
on includes this feature.  Switching manually is a pain. I always forget
to do it, so I have to quit the game, go to the Monitors control panel,
switch resolutions, then relaunch the game! What a pain! I hate when I
forget to do it!

Now, back to buisness:

I'm pretty sure that the QuickTime 2.1's BeginFullScreenMode() call
requires Display Manager 2.0 to switch resolutions.  When QuickTime 2.1
came out, I tried using this call, but didn't get a resolution switch.  It
hid the menu bar, and it created a full screen window, but the monitor
didn't switch to 640x480 like I requested.  I was using a Q630 and a 7100,
both with System 7.5.

I haven't tried it since installing Display Enabler 2.0, but I assume this
was the missing piece.

In Warcraft, we used the sample code from the Display Manager Developer
Kit, which is on the Developer CDs.  It allows switching resolutions with
Display Manager 1.0 or 2.0.  With DM 1.0, you should only use this sample
code to switch resolutions if there is one monitor.  With multiple
monitors, it won't "gravitate" the monitors so that they are all touching
on the desktop.  DM 2.0 will always do this for you.

Display Manager 1.0 is included with all PowerMacs (System 7.1.2), and
with System 7.5.   Display Manager 2.0 is included in all System software
after 7.5.1, including 7.5.2 with the PCI Macs.  It is also available as
an extension from Apple at:

<ftp://ftp.info.apple.com//Apple.Support.Area/Apple.Software.Updates/US/
Macintosh/Display_and_Peripheral/Display_Software_2.0.sea.hqx>


Display Manager can be licensed from Apple, no charge.

There are a few things to look out for if you want to use the sample
code.  On PPC, the calls that are new to DM 2.0 require the Display
Library in addition to Display Enabler 2.0.  Display Library is included
in the Display Manager Developer Kit.  It is NOT installed on PCI Macs,
even though they ship with DM 2.0.  If you want to use DM 2.0 calls on a
PPC, you must either install Display Library into the Extensions folder
(or your app's folder), or compile it into your application.  (I'm not
sure how, but I know its possible.)

Also, the sample code correctly looks for the version of DM using Gestalt
before making DM calls, but it doesn't look to see if Display Library is
loaded.  If you "weak link" DiaplyLib, you can run without Display
Library, but you must do this before making DM 2.0 calls:

#if GENERATINGCFM
if ( (Ptr) DMGetDisplayMode == (Ptr) kUnresolvedCFragSymbolAddress ) {
   // Display Manager 2.0 is NOT installed.
}
#endif


The other problem with switching resolutions is those pesky finder icons!
When you shrink your monitor size, the Finder's icons are repositioned,
but when you increase resolution again, they don't move back, so they end
up in the middle of the monitor.  The icons are repositioned when the
Finder gets an event from Display Manager telling it that the display
configuration has changed.

One of the programmers of Shockwave Assault explained a while back how
they avoided this problem.  First, they don't procces events between
resolution switches.  Second, they don't call DMEndConfigureDisplays()
until after the second resolution switch, so when the Finder gets that
event from Display Manager, the resolution is back to its original
settings, so no icon repositioning is needed.

This clever technique works OK for games that take over the computer and
don't process events, but it won't work if you want to allow switching to
other applications or to the Finder while the game is running.  The Finder
icons will be offscreen, along with other applications' windows.

Another possible solution to the icon problem is to use AppleEvents to get
the icon positions and restore them when the game quits, like Quinn's
Snapshotter utility does.  I looked into this a little bit, but I haven't
had time to figure out the necessary AppleEvent stuff yet.


So, if you want resolution switching, license Display Manager 2.0 from
Apple, and include it with your game.  If you are going to require
QuickTime 2.1 for your game, use the BeginFullScreenMode() call.  If you
don't want to require QT 2.1, use the sample code in the DM Dev. Kit.  It
is simple to use - just include the source files, and make a few calls in
your code.  (Just don't forget to add the check for Display Library.)

If anyone writes code to reposition Finder icons, I'm sure no one will
complain if you post it here!


    David Lawrence
    Future Tense

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 25 Feb 1996 11:54:23 GMT
Organization: Ecole Normale Superieure, Paris, France

In article <[e-mail]>,
David Lawrence <[e-mail]> wrote:

>If anyone writes code to reposition Finder icons, I'm sure no one will
>complain if you post it here!

Full source code to do this appeared on the Develop CD about a year
ago.

--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Meggs)
Date: Sat, 24 Feb 1996 16:29:16 GMT
Organization: University of Virginia

In article <[e-mail]>,
[e-mail] (David Lawrence) wrote:
>
> There are a few things to look out for if you want to use the sample
> code.  On PPC, the calls that are new to DM 2.0 require the Display
> Library in addition to Display Enabler 2.0.  Display Library is included
> in the Display Manager Developer Kit.  It is NOT installed on PCI Macs,
> even though they ship with DM 2.0.  If you want to use DM 2.0 calls on a
> PPC, you must either install Display Library into the Extensions folder
> (or your app's folder), or compile it into your application.  (I'm not
> sure how, but I know its possible.)
>

You don't compile it into your application, rather, you include it as
a code fragment in your application's data fork along with the fragment
containing the app's own code. The CFM is more flexible than most people
realize -- you can put more than one fragment in a single file, provided
that you set up the 'cfrg' resource correctly.

Luckily, Apple provides an MPW tool to do this for us, called "mergefragment".
For development, I just use CW to build the app, and leave Display Library
in the same folder. But when I send a copy off my machine, I run this
little MPW/ToolServer script:

  duplicate -y "development app" "distribution app"
  mergefragment -p "Display Library" "distribution app"

And then I've got a file called "distribution app" that contains both the
fragment from the CW build and the Display Library fragment.

--
_________________________________________________________________________
andrew meggs                               the one who dies with the most
[e-mail]                              AOL free trial disks wins

+++++++++++++++++++++++++++

>From [e-mail] (John W. Blackburne)
Date: Mon, 26 Feb 1996 21:30:07 +0800
Organization: Tempest

In article <[e-mail]>,
[e-mail] (Chris De Salvo) wrote:

:In article <[e-mail]>,
:[e-mail] (R. T. Chancellor) wrote:
:
:>Shockwave Assault has a really nice option that dynamically resets the
:>monitor's resolution so that you get full screen action. It then resets
:>the resolution back (upon quitting) so that the Finder does not do that
:>pesky shuffle of icons to fit on the Desktop.
:>
:>Does anyone know where I might get a code example of how to do this (in C) ?
:
:[...]
:
:2)  Use the Display Manager routines.  However, doing this requires that
:you have to have System 7.5 or newer to make sure that the Display Manager
:is present.

I think the requirement is 7.1.2 or later - Display Manager version 1 is
part of the standard system software on all PowerPC Macs, which was the
only way to get  7.1.2. I'm not sure what you get if you install 7.1.2 on
68k Macs. It then appeared in System 7.5, along with almost every other
system software component released in the previous 2 years.

Version 2 of the dispaly manager, which you need to suppport resolution
switching with 2 or more monitors, is built into System 7.5.2, comes with
some monitors and will probably also appear in System 7.5.3/System Update
2.0. It's also avaialble as an extension & shared library which I think is
freely licenceable for distribution if you subscribe to the MacOS
SDK/developer subscription.

John
--
John Blackburne,                     [e-mail]
Programmer  Asia, Inc. Online:       http://www.asia-inc.com
Technology consultant and trainer:   http://www.hk.super.net/~johnb

+++++++++++++++++++++++++++

>From [e-mail] (Jan Melander)
Date: Mon, 26 Feb 1996 15:49:14 GMT
Organization: WM-Data

In article <[e-mail]>,
[e-mail] (Chris De Salvo) wrote:

>In article <[e-mail]>,
>[e-mail] (R. T. Chancellor) wrote:
>
>>Shockwave Assault has a really nice option that dynamically resets the
>>monitor's resolution so that you get full screen action. It then resets
>>the resolution back (upon quitting) so that the Finder does not do that
>>pesky shuffle of icons to fit on the Desktop.
>>
>>Does anyone know where I might get a code example of how to do this (in C) ?
>
>Well, you got two real options.
>
>1)  Use the new QuickTime 2.1 call BeginFullScreenMode().  It's a rad
>call.  All at once it can:
>
>   o Hide the menubar
>   o Change the monitor resolution
>   o Create a full-screen window for you
>   o Clear the window to a particular RGB color
>
>   Not bad for one function call.
>
>2)  Use the Display Manager routines.  However, doing this requires that
>you have to have System 7.5 or newer to make sure that the Display Manager
>is present.
>
>L8R
>Chris
>

One bad thing tough...
When I started the Shockwave demo my Gravis MouseStick II driver loaded
the appropriate stick set but also remebered the screen size, so when the
game changed the screen size the center position of the joystick was way
off!!!

Otherwise this is a great idea,  Gravis are You listening?

Cheers,

--
- -------------------------------------------------------------
        Jan Melander
        WM-Data
        [e-mail]
- -------------------------------------------------------------
Q:Why didn't Intel name their CPU 586 instead of Pentium?
A:When they added 100 to 486 the readout said 585.9999999999765,
  and it didn't fit on the chip.

+++++++++++++++++++++++++++

>From [e-mail] (Chris Conway)
Date: Tue, 27 Feb 1996 00:49:22 -0800
Organization: Electronic Arts

> When I started the Shockwave demo my Gravis MouseStick II driver loaded
> the appropriate stick set but also remebered the screen size, so when the
> game changed the screen size the center position of the joystick was way
> off!!!
>
> Otherwise this is a great idea,  Gravis are You listening?

Hmmmm.  I tested the game with a few joysticks, and the Gravis MouseStick
was the only one that handled the monitor change successfully for me!
Maybe you don't have the latest Gravis software or I was just lucky...

This is a problem that the joystick people need to address...  I think
more and more games are going to start doing this (it's a really nice
feature) and it isn't very nice if you're joystick software can't handle
it.

Chris Conway
Electronic Arts

+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: Tue, 27 Feb 1996 00:27:23 -0500
Organization: qualia, inc.

In article <[e-mail]>,
[e-mail] (Jan Melander) wrote:

# One bad thing tough...
# When I started the Shockwave demo my Gravis MouseStick II driver loaded
# the appropriate stick set but also remebered the screen size, so when the
# game changed the screen size the center position of the joystick was way
# off!!!

I had a similar problem in using the Apple source. I haven't yet figured
out a way around it, are there any suggestions?

--
[e-mail]
http://www.qualia.com/~bwade/

+++++++++++++++++++++++++++

>From [e-mail] (Jon Blossom)
Date: Tue, 27 Feb 1996 18:59:07 GMT
Organization: (none)

>Does anyone know where I might get a code example of how to do this (in C) ?

My article in the next Game Developer magazine (April/May issue)
includes complete code for switching the monitor resolution and
creating a full-screen double-buffered environment using GWorlds. The
code uses Display Manager 2.0 and doesn't include all the features you
might want (hey, it's in a magazine!), but it's a good start, and I
think it's more immediately understandable than the Apple sample code.

-Jon Blossom
[e-mail]



---------------------------

>From Howard Salmon <[e-mail]>
Subject: Do all functions -procedures allocate memory?
Date: 28 Feb 1996 06:43:32 GMT
Organization: Arizona Daily Star - AZSTARNET

Advice from Inside Mac is that we should lock blocks of memory
sparingly, lest we call a function that "allocates memory".

My questions:
1.  How does a function "allocate" memory?  Doesn't it make a call for
memory?  I thought the Memory Manager allocated the memory.

2. Don't all functions allocate memory?

3. How to decide which blocks to lock?  --or--How to determine which
functions allocate memory?

These questions inspired by the Inside Mac passage which reads:
"the handle myData needs to be locked before the WITH statement because
the functions TENew and GetNewControl allocate memory and hence might
move the block whose handle is myData."

Any clarification for my confused novice mind would be greatly
appreciated. --Howard Salmon ([e-mail])



+++++++++++++++++++++++++++

>From [e-mail] (Tom Johnstone)
Date: Wed, 28 Feb 1996 20:08:39 +0100
Organization: University of Geneva

As another Mac programming novice I would also like to know the answer to
this question. It seems that one is able to either use LOCK to prevent a
block of data (say the value of a variable) from being moved, or one can
use a local variable to save the data before calling the "memory
allocating" function. I read something about this in the Think Pascal
manual, but I don't really understand it. Could people post me their
replies too please?

Thanks for the help
Tom

In article <4h0tik$[e-mail]>, Howard Salmon
<[e-mail]> wrote:

>My questions:
>1.  How does a function "allocate" memory?  Doesn't it make a call for
>memory?  I thought the Memory Manager allocated the memory.
>
>2. Don't all functions allocate memory?
>
>3. How to decide which blocks to lock?  --or--How to determine which
>functions allocate memory?
>
>These questions inspired by the Inside Mac passage which reads:
>"the handle myData needs to be locked before the WITH statement because
>the functions TENew and GetNewControl allocate memory and hence might
>move the block whose handle is myData."
>

o---------------------------------------------------------------------o
| Tom Johnstone                                                       |
| Faculte de Psychologie                Tel.  [phone]         |
| et des Sciences de l'Education        Fax   [phone]         |
| Universite de Geneve                                                |
| 9, route de Drize                                                   |
| CH-1227 Carouge-Geneve          email: [e-mail]      |
|                                                                     |
| http://www.unige.ch/fapse/emotion/members/johnston/johnston.html    |
o---------------------------------------------------------------------o

+++++++++++++++++++++++++++

>From [e-mail] (Don Sample)
Date: Thu, 29 Feb 1996 16:54:57 -0500
Organization: Enerprise Solutions Ltd

In article <4h0tik$[e-mail]>, Howard Salmon
<[e-mail]> wrote:

>My questions:
>1.  How does a function "allocate" memory?  Doesn't it make a call for
>memory?  I thought the Memory Manager allocated the memory.
>
>2. Don't all functions allocate memory?
>
>3. How to decide which blocks to lock?  --or--How to determine which
>functions allocate memory?
>
>These questions inspired by the Inside Mac passage which reads:
>"the handle myData needs to be locked before the WITH statement because
>the functions TENew and GetNewControl allocate memory and hence might
>move the block whose handle is myData."
>

1: There are generally two ways to allocate memory.  On the stack, or in
the heap. Function parameters and local variables are allocated on the
stack (They may also be in registers, but you don't usually have to worry
about that).  You can also allocate memory dynamically in the heap using
Memory Manager functions such as NewHandle and NewPointer.

2: It is possible to write functions which do not allocate any memory.  If
they don't have any parameters, or local variables then no memory will be
allocated for them.

3: When to lock:
    a)  You only lock data allocated through NewHandle (or one of its close
        relatives)
    b)  You only lock a handle if you dereference it, and then make a call
        to something which may move memory.  The Pascal WITH statement is
        particularily nasty in this respect because it does an implicit
        dereference of a handle behind your back (hence the IM warning).
    c)  rather than locking handles it is often preferable to either
        re-arrange your code, or make local copies of the data in the
        handle.

--
Don Sample ([e-mail])           |  Quando Omni Flunkus
Enterprise Solutions Ltd.               |        Moritati
http://www.esltd.com/esl_people/sample/ |

+++++++++++++++++++++++++++

>From <[e-mail]>
Date: 2 Mar 1996 06:42:36 GMT
Organization: FlexNet Inc, HAWAII

Howard Salmon <[e-mail]> wrote:
>Advice from Inside Mac is that we should lock blocks of memory
>sparingly, lest we call a function that "allocates memory".
>
>My questions:
>1.  How does a function "allocate" memory?  Doesn't it make a call for
>memory?  I thought the Memory Manager allocated the memory.
>
>2. Don't all functions allocate memory?
>
>3. How to decide which blocks to lock?  --or--How to determine which
>functions allocate memory?
>
>These questions inspired by the Inside Mac passage which reads:
>"the handle myData needs to be locked before the WITH statement because
>the functions TENew and GetNewControl allocate memory and hence might
>move the block whose handle is myData."
>
>Any clarification for my confused novice mind would be greatly
>appreciated. --Howard Salmon ([e-mail])
>

..ask tricky questions, get tricky answers...

Keep studying Inside Mac. Apple emphasizes allocating memory dynamically, accessing it
via handles, and locking it down when you're using it. ONLY whe
n you're actively using
it, though, else you break the concept of relocatable memory blocks. Like, if you're
about to write to the memory, or call an OS trap that'll write to it, lock it
down...then unlock it right away, after you're done writing, so the memory block can
float around in the physical RAM if it needs to.

Sometimes Inside Mac tells you explicitly to lock down a routine, as you said in
your example...that's an exception to the rule. Follow their advice. If an OS trap
allocates me
mory, Apple generally tells you so (hint: if they say you can't use a
function during interrupts, it's probably because it allocates memory).

Lots of Mac OS traps allocate some memory to do their work. If you're passing data
to one of those functions, you'll often lock down your data so it doesn't get moved
around when the function asks for some memory. Otherwise the trap would write to
where your data USED to be (with wildly unpredictable results!).

Read up on how the stack is compressed and defragmented by the Memory Mgr. Remember
to unlock your locked handles after you (or the Mac trap) are done using them;
if you don't further need them in the program, release them with a Dispose function.

One thing that does confuse lots of people is that all functions (C, same with other
languages) do use memory...but they take stack memory, not dynamically allocated
blocks. Stack memory is fixed when the C program begins execution; in CW and Symantec,
you set it in a dialog (you can also set it directly, as in MPW, using a Mac trap).
A C function stores the context (the caller, the return address, called a frame),
the parameters passed to it, and the local variables, all on the stack. If that
function calls other functions, they, too, add to the stack demands. It all adds up
and the bigger the nested set of functions, the more stack needed.



+++++++++++++++++++++++++++

>From [e-mail] (Dave Nebinger)
Date: Fri, 01 Mar 1996 09:50:42 -0500
Organization: KHP Services, Inc

In article <[e-mail]>,
[e-mail] (Don Sample) wrote:

> 2: It is possible to write functions which do not allocate any memory.  If
> they don't have any parameters, or local variables then no memory will be
> allocated for them.

Depending on the settings for your compiler and optimizer, you may still
generate
a stack frame for a function on the stack whether it has parms & locals or
not.

> 3: When to lock:
>     a)  You only lock data allocated through NewHandle (or one of its close
>         relatives)
           Be sure to include the GetResource() routines as "one of the
close relatives".

>     c)  rather than locking handles it is often preferable to either
>         re-arrange your code, or make local copies of the data in the
>         handle.

It hardly seems worth it to rearrange code or make temporary copies if you
just need a quick dereference of the handle's data.  HLock() and HUnlock()
are more appropriate and faster.

However, you do want to avoid the practice of allocating a handle and locking
it, unless the handle's lifetime is very short.  Only HLock() when you need to,
and HUnlock() as soon as you are able.

Dave.

==========================================================
Dave Nebinger                             [e-mail]
             The Alt.Sources.Mac Archivist
     <http://www.AmbrosiaSW.com/alt.sources.mac/>
    <ftp://ftp.AmbrosiaSW.com/pub/alt.sources.mac/>

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 28 Feb 1996 17:45:01 -0800
Organization: Apple Computer, Inc.

In article <4h0tik$[e-mail]>
Howard Salmon <[e-mail]> wrote:

 > Advice from Inside Mac is that we should lock blocks of memory
 > sparingly, lest we call a function that "allocates memory".

All such advice is necessarily an overgeneralization. The key fact is that
Memory Manager attempt to coalesce multiple free blocks and move allocated
blocks around to make optimal use of the existing space inside a heap. If
you lock a block down in the middle of the heap, Memory Manager has fewer
options than if you had first called MoveHHi. Functions which allocate
memory are the ones which generally cause the heap to shuffle like this,
although other calls like MoveHHi do as well.

 > 1.  How does a function "allocate" memory?  Doesn't it make a call for
 > memory?  I thought the Memory Manager allocated the memory.

NewPtr, NewHandle. Yes, the aforementioned two calls and variants on them. Yes.

 > 2. Don't all functions allocate memory?

There are two answers here.

[1] If you have a function 'foo' in your program and it lives in the same
code segment as function 'bar' and 'foo' calls 'bar' and 'bar' doesn't
call any functions which move memory or live in another code segment,
'bar' will not move memory. For example:

    static unsigned long bar (void)
    {
        return 12;
    }

    static void foo (void)
    {
         unsigned long b = bar ( );
    }

[2] Most system calls move memory. Most of the ones that don't these days
are the ones used by Memory Manager to move memory. :-) For example,
StripAddress, BlockMove. Other calls which don't move memory include
asynchronous i/o calls, which can't move memory because they're supposed
to be callable at interrupt time, when memory might be moving.

 > 3. How to decide which blocks to lock?  --or--How to determine which
 > functions allocate memory?

The basic rule I follow these days just because I'm getting to be a
conservative old man is to assume all calls move memory. That's not true,
but it serves me well. It doesn't mean you have to lock any handles you
have lying around whenever you call any old routine.

The only time you need to lock a handle is when you get a copy of its
master pointer and want to keep it around across a call or want to pass it
to a routine which might not know it is getting a copy of a master pointer
of an unlocked handle or might be in another segment. Here's how you might
get a copy of a master pointer:

    static void baz (Ptr p)
    {
        // do something that moves memory
        char c = *p;
        // c may now be bogus because the block
        // referred to by 'h' below may have moved
    }

    static void quux (Handle h)
    {
        baz (*h); // master pointer of presumably unlocked handle
    }

OK, but how do you avoid this without taking the time to lock the handle?
Well, note that 'baz' doesn't really need 'p', it just needs 'c'. 'baz'
could be redefined to accept a 'char' instead of a 'Ptr'. That would make
the problem go away, because 'quux' would simply pass '**h' instead of
'*h'. It's quite often the case that you'll save code space and debugging
time by simply copying the small pieces you need out of a handle and
passing them around instead of the handle itself or the handle's master
pointer. If you did want to pass the master pointer around, 'quux' should
probably be rewritten to look something like this:

    static OSErr quux2 (Handle h)
    {
        OSErr err = noErr;

        char hState = HGetState (h); // save 'locked' bit
        if (!(err = MemError ( )))
        {
            MoveHHi (h);
            if (!(err = MemError ( )))
            {
                HLock (h);
                if (!(err = MemError ( )))
                {
                    bax (*h);
                    HSetState (hState,h); // restore 'locked' bit
                    if (!err) err = MemError ( );
                }
            }
        }

        return err;
    }

Note: I wrote this code off the top of my head. It probably doesn't even
compile. Your mileage may vary. One vehicle at this price. Void where
prohibited.

 > These questions inspired by the Inside Mac passage which reads:
 > "the handle myData needs to be locked before the WITH statement because
 > the functions TENew and GetNewControl allocate memory and hence might
 > move the block whose handle is myData."

The WITH statement in question probably half-deferences a handle as in
'baz', above.

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From Paulo Casanova <[e-mail]>
Date: Sun, 3 Mar 1996 13:15:08 +0000
Organization: Instituto Superior Tecnico


> As another Mac programming novice I would also like to know the answer to
> this question. It seems that one is able to either use LOCK to prevent a
> block of data (say the value of a variable) from being moved, or one can
> use a local variable to save the data before calling the "memory
> allocating" function. I read something about this in the Think Pascal
> manual, but I don't really understand it. Could people post me their
> replies too please?
>
> Thanks for the help
> Tom

  You guys must get a list of the toolbox functions that move memory. I
use THINK reference. I think that there are more programs that will do.

Paulo

+++++++++++++++++++++++++++

>From [e-mail] (Don Sample)
Date: Tue, 05 Mar 1996 15:13:25 -0500
Organization: Enerprise Solutions Ltd

In article <[e-mail]>,
Paulo Casanova <[e-mail]> wrote:
>
>  You guys must get a list of the toolbox functions that move memory. I
>use THINK reference. I think that there are more programs that will do.
>
>Paulo

Generally it is safest to assume that all functions and procedures may
cause memory to move, for a few reasons:

1:  Think Reference's indications on which functions move memory aren't
always correct.

2:  Just because something doesn't move memory now, doesn't mean that it
won't move memory in some future OS release (or, if it is one of your own
functions, your next version).

3:  Even if Apple's version of a routine doesn't move memory, who knows
what some of those 3rd party extensions you have loaded are doing with
routines they have patched.

There are a few functions, such as BlockMove, which are pretty safe to
assume will not move memory, but for the most part you are better safe
than sorry.

--
Don Sample ([e-mail])           |  Quando Omni Flunkus
Enterprise Solutions Ltd.               |        Moritati
http://www.esltd.com/esl_people/sample/ |

---------------------------

>From [e-mail] (Private Pile)
Subject: Drawing behind TE fields
Date: Wed, 28 Feb 1996 22:37:42 GMT
Organization: University of Waterloo

I'm writing an App which requires some fairly basic use of TextEdit.
However, I want to have a picture behind my TE Field. Does anyone know
an good way to do this?

Would installing a custom DrawHook work, or is that only for drawing
text, not the background?

Thanks in advance,
Nick
--
"Just remember, Mr Fawlty, there's always somebody worse off than yourself."
"Is there? Well I'd like to meet him. I could do with a laugh."

+++++++++++++++++++++++++++

>From [e-mail] (John S. Heaney)
Date: 29 Feb 1996 03:27:00 -0800
Organization: CRL Dialup Internet Access    [phone]  [Login: guest]

In article <[e-mail]>,
Private Pile <[e-mail]> wrote:
>I'm writing an App which requires some fairly basic use of TextEdit.
>However, I want to have a picture behind my TE Field. Does anyone know
>an good way to do this?

The best way I have found is to install a grafproc bottleneck routine for
the StdRect routine. You install the bottleneck callback just before
drawing your text and uninstall it just after. Your routine does nothing.
This prevents TextEdit or TextBox from erasing the background. Oh yeah,
you also have to set the text mode to srcOr.

Keep in mind that this works best for static text. If you want to scroll
the text or change the text (like if it's editable) you have to refresh
the background because you're drawing in srcOr mode. Otherwise, the text
keeps writing over itself, which gets messy quickly.

--
John Heaney              Time flies whether you're having fun or not.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Fri, 01 Mar 1996 00:58:10 -0800
Organization: MacPlay

In article <[e-mail]>,
[e-mail] (Private Pile) wrote:

>I'm writing an App which requires some fairly basic use of TextEdit.
>However, I want to have a picture behind my TE Field. Does anyone know
>an good way to do this?
>
>Would installing a custom DrawHook work, or is that only for drawing
>text, not the background?

There is sample code for this on Apple's ftp site.  I can't get in right
now otherwise I'd give the URL.

Actually, what you want to do is to replace the QuickDraw bottleneck
routines for rects and regions.  Specifically, you want to trap the
'erase' GrafVerb.  Rather than filling with the current background color
like StdRect/StdRgn do you would blit in the appropriate area from your
graphic.

That's an overly simplistic answer but that's it in a nutshell.  If you go
to Apple's ftp site and look through the code snippets area you should
find it.  It's called something like TE Over Pict or something similar.

L8R
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

+++++++++++++++++++++++++++

>From [e-mail] (Phil Weiss)
Date: 1 Mar 1996 20:52:38 GMT
Organization: American Information Systems, Inc.

In article <[e-mail]>,
[e-mail] (Private Pile) wrote:

> I'm writing an App which requires some fairly basic use of TextEdit.
> However, I want to have a picture behind my TE Field. Does anyone know
> an good way to do this?
>
> Would installing a custom DrawHook work, or is that only for drawing
> text, not the background?
>
> Thanks in advance,
> Nick
> --
> "Just remember, Mr Fawlty, there's always somebody worse off than yourself."
> "Is there? Well I'd like to meet him. I could do with a laugh."


  What happens is 'TEUpdate' calls 'EraseRect'.  So, what worked for me
was to patch 'EraseRect' before calling 'TEUpdate':


savdAddr = gettrapaddress of 'EraseRect';

SetTrapAddress of 'EraseRect' to your own 'MyEraseRect';  which does nothing.

Call 'TEUpdate'.

SetTrapAddress of 'EraseRect' back to savdAddr.

--
Phil

---------------------------

>From [e-mail] (Kenneth Wayne Land)
Subject: How Often Do I Lock a Handle?
Date: Mon, 26 Feb 1996 23:56:50 -0500
Organization: InternetMCI

I am programming in C using CodeWarrior 68K.  If I have a function that
needs to lock a handle to some data and while that handle is locked, I
call another function that gets a handle to the same data, does the second
handle also need to be locked  (assuming both functions make toolbox calls
that may move the data)?  In other words, is it necessary to "nest" HLock
and HUnlock when more than one function is accessing the same data, each
using it's on allocated handle?  Or should I be passing the handle to the
second function?  Any help is much appreciated.  The people in this news
group are GREAT!  Thanks!

Wayne Land, Ft. Lauderdale, FL
(trying to develop some music education software)

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Tue, 27 Feb 1996 01:17:48 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Kenneth Wayne Land) writes:
>  If I have a function that
> needs to lock a handle to some data and while that handle is locked, I
> call another function that gets a handle to the same data, does the second
> handle also need to be locked  (assuming both functions make toolbox calls
> that may move the data)?  In other words, is it necessary to "nest" HLock
> and HUnlock when more than one function is accessing the same data, each
> using it's on allocated handle?

No; in fact, you shouldn't nest them.

You're really locking and unlocking the *data*, not the handle.
(Actually this is a terminological nightmare; NIM generally uses the
word "handle" when they're talking about the data, so it makes sense
for them to say "locking the handle", but it leaves a lot of confused
newbies.) If two functions have Handle variables which point to the
same data, and one of them calls HLock on it, the data will be locked
for both.

You can see why nesting HLock / HUnlock is bad:
FuncA locks handle (now the data is locked)
FuncA calls FuncB
  FuncB locks handle (this has no effect, since it's already locked)
  FuncB does work
  FuncB unlocks handle (now the data is unlocked)
  FuncB returns
FuncA does work (crash, since the data is unlocked now)

If your program style requires this sort of nesting, you can use
HGetState and HSetState to store a handle's state, HLock it, and then
return the handle to the stored state.

Or you can decide that some functions lock handles, and other
functions require their handles to be locked, and make sure the second
kind is only called from the first kind. (Hint: comment each
function.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Kenneth Wayne Land)
Date: Tue, 27 Feb 1996 13:27:49 -0500
Organization: InternetMCI

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

> No; in fact, you shouldn't nest them.
>
> You're really locking and unlocking the *data*, not the handle.
> (Actually this is a terminological nightmare; NIM generally uses the
> word "handle" when they're talking about the data, so it makes sense
> for them to say "locking the handle", but it leaves a lot of confused
> newbies.) If two functions have Handle variables which point to the
> same data, and one of them calls HLock on it, the data will be locked
> for both.

Thanks so very much for responding.  This is an area that should be more
clearly explained in many texts and is not.  I say again, this newsgroup
is "fabulous".

---------------------------

>From [e-mail] (Jeremy Friesen)
Subject: Limiting the mouse region
Date: 27 Feb 1996 06:17:39 GMT
Organization: Singularity

Ok, so here's a mouse cursor problem.

I'm hiding the mouse cursor, and using the mouse position to control a
simple game. I grabbed the screen bounds and use them to scale the mouse
input, so that maximum movement is at the edges of the screen. This works
great, until today I plugged a second monitor into my mac for the first
time today.  So now what happens is that the mouse is able to move off the
main screen onto the secondary screen during game play, even though the
actual cursor is hidden. This is a problem, because since the edge of the
main screen is calibrated to be maximum movement, moving the mouse past
that edge causes major bad problems.  I could simply crop the mouse
position to be withing the main screen, but the cursor would still be off
on the other screen, and would take more movement to get mack within
bounds. So what I want is a way to keep the mouse cursor within a certain
rect or region.  Is this possible? If not, what other solutions are there?
Thanks very much.
_________________________________________________________________
              J E R E M Y         The J-Files
            F R I E S E N         The Jeremy's Out There...
         [e-mail]         No web page for now.
               Assume reality is negligible...
_________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Chris De Salvo)
Date: Wed, 28 Feb 1996 04:00:11 -0800
Organization: MacPlay

In article <[e-mail]>,
[e-mail] (Jeremy Friesen) wrote:

>I'm hiding the mouse cursor, and using the mouse position to control a
>simple game. I grabbed the screen bounds and use them to scale the mouse
>input, so that maximum movement is at the edges of the screen. This works
>great, until today I plugged a second monitor into my mac for the first
>time today.  So now what happens is that the mouse is able to move off the
>main screen onto the secondary screen during game play, even though the
>actual cursor is hidden. This is a problem, because since the edge of the
>main screen is calibrated to be maximum movement, moving the mouse past
>that edge causes major bad problems.  I could simply crop the mouse
>position to be withing the main screen, but the cursor would still be off
>on the other screen, and would take more movement to get mack within
>bounds. So what I want is a way to keep the mouse cursor within a certain
>rect or region.  Is this possible? If not, what other solutions are there?
>Thanks very much.

1)  What I do is hide the cursor, and then read mouse movement DELTAS.
Rather than using the absolute position of the mouse in QuickDraw space to
position my cursor I keep my own variables for the mouse position.  I then
read how much the mouse has moved from the last time I checked.  I use
that delta to change my internal cursor coordinates.

I then just clip those coordinates against my game monitor bounds and I'm
done.  I haven't had any problems with this technique so far.

2)  Another method that you could use would be to use the Cursor Devices
Manager.  It provides calls that allow you to change the mouse position.
You could then check to see if the mouse moved outside your boundaries and
if it did, you could move it back to within your valid range.

Personally, I prefer #1.

Good luck,
Chris

--
[e-mail]         |   Macintosh:  Changing the world,
Chris De Salvo              |        one person at a time!
Professional Mac Geek       |    -----------------------------
for MacPlay, Inc.           |      (I wish they'd hurry up!)

           http://www.deltanet.com/users/phixus

---------------------------

>From [e-mail] (Chris S. Dillman)
Subject: MOVE 16
Date: 26 Feb 1996 20:21:29 GMT
Organization: Cloudnet, St. Cloud MN (612)-240-8259 login as guest

Hi out there.

I have seen mention of MOVE 16 command for use on 040s.
My questions are.
How dose it work?
Is it availible on all 040 including 040LC?
Can I get CW C/C++ to generate it?
LIke when i copy between 2 Ptr say (double*)ptr or somthing.

BYBY



+++++++++++++++++++++++++++

>From [e-mail] (Jason Regier)
Date: Mon, 26 Feb 1996 13:52:40 -0800
Organization: Qualcomm, Inc.

In article <4gt4o9$[e-mail]>, [e-mail] (Chris S.
Dillman) wrote:
> I have seen mention of MOVE 16 command for use on 040s.
> How does it work? Is it availible on all 040 including 040LC?
> Can I get CW C/C++ to generate it?
>
MOVE16 is an instruction to copy 16 bytes from one address to another.  It
should be faster than 4 successive MOVE.L instructions, if only because it
eliminates the instruction fetches and other overhead.  From what I recall
from the Motorola handbooks, in order for it to work most efficiently,
your source and destination must both be aligned on 16 byte boundaries.
And I think it's available on all 040s (including LC040 and EC040) and
higher 68K processors.   And yes, CW C/C++ (as with most good 68K
compilers) should generate MOVE16 instructions when appropriate.

Jason

--
Jason Regier
GlobalStar Software Engineer
QUALCOMM, Inc.
[phone]
[e-mail]

+++++++++++++++++++++++++++

>From Andrew Barry <[e-mail]>
Date: Tue, 27 Feb 1996 11:52:38 +1000
Organization: Connect.com.au P/L, Sydney, Australia

> MOVE16 is an instruction to copy 16 bytes from one address to another.  It
> should be faster than 4 successive MOVE.L instructions, if only because it
> eliminates the instruction fetches and other overhead.  From what I recall
> from the Motorola handbooks, in order for it to work most efficiently,
> your source and destination must both be aligned on 16 byte boundaries.
> And I think it's available on all 040s (including LC040 and EC040) and
> higher 68K processors.   And yes, CW C/C++ (as with most good 68K
> compilers) should generate MOVE16 instructions when appropriate.

MOVE16 can only be used where source and destination are aligned to 16 byte
boundaries. It works by copying the entire cache entry (which is 16 bytes long) -
and also avoids having to load the cache if the destination block isn't currently
in the cache. If you call it with an unaligned address, I think it just grabs the
previous cache entry (ie it ignores the bottom four bits).

Additionally, other than the hand-coded implementation of memcpy, I wouldn't think
that any 68k compiler would bother to try and generate MOVE16 instructions (don't
overly flame me if I'm wrong) - since MOVE16 can only be used for large structure
copies, and the compiler would presumably call a memcpy equivalent routine
(there is a lot more 'lower hanging fruit' for optimisations).

Just my opinion...

Andrew Barry

+++++++++++++++++++++++++++

>From [e-mail] (Chris S. Dillman)
Date: 27 Feb 1996 17:17:45 GMT
Organization: Cloudnet, St. Cloud MN (612)-240-8259 login as guest

Chris S. Dillman ([e-mail]) wrote:
: Hi out there.

: I have seen mention of MOVE 16 command for use on 040s.
: My questions are.
: How dose it work?
: Is it availible on all 040 including 040LC?
: Can I get CW C/C++ to generate it?
: LIke when i copy between 2 Ptr say (double*)ptr or somthing.

: BYBY

Thanx guys

now whats a EC040 chip?




+++++++++++++++++++++++++++

>From [e-mail] (Jason Regier)
Date: Tue, 27 Feb 1996 11:08:50 -0800
Organization: Qualcomm, Inc.

In article <4gvebp$[e-mail]>, [e-mail] (Chris S.
Dillman) wrote:

> now whats a EC040 chip?

It's the Embedded Controller version of the 68040.  If I remember
correctly, it doesn't have an FPU or MMU.  All Macs come with either a
68040 or a 68LC040, though, so it's not something you're likely to have to
worry about.  As far as I know, the EC040 is typically used in embedded
controller applications where you don't need floating point calculations.

Jason

--
Jason Regier
GlobalStar Software Engineer
QUALCOMM, Inc.
[phone]
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris S. Dillman)
Date: 28 Feb 1996 17:30:46 GMT
Organization: Cloudnet, St. Cloud MN (612)-240-8259 login as guest

Jason Regier ([e-mail]) wrote:
: In article <4gvebp$[e-mail]>, [e-mail] (Chris S.
: Dillman) wrote:

: > now whats a EC040 chip?

: It's the Embedded Controller version of the 68040.  If I remember
: correctly, it doesn't have an FPU or MMU.  All Macs come with either a
: 68040 or a 68LC040, though, so it's not something you're likely to have to
: worry about.  As far as I know, the EC040 is typically used in embedded
: controller applications where you don't need floating point calculations.

COOL thanx everyone.



+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 28 Feb 1996 16:43:49 GMT
Organization: UCLA, Computer Science Department

In article <[e-mail]> [e-mail] (Jason Regier) writes:
>In article <4gt4o9$[e-mail]>, [e-mail] (Chris S.
>Dillman) wrote:
>> I have seen mention of MOVE 16 command for use on 040s.
>> How does it work? Is it availible on all 040 including 040LC?
>> Can I get CW C/C++ to generate it?
>>
>MOVE16 is an instruction to copy 16 bytes from one address to another.  It
>should be faster than 4 successive MOVE.L instructions, if only because it
>eliminates the instruction fetches and other overhead.

Yup. MOVE16 uses the on-chip cache to perform the moves. As such, only
one read and one write are done to memory, instead of two reads and one
write.

>From what I recall
>from the Motorola handbooks, in order for it to work most efficiently,
>your source and destination must both be aligned on 16 byte boundaries.

If memory serves, the source and destination _must_ be aligned on 16
byte boundries (might be wrong about this though; don't have my manual
here at work).

>And I think it's available on all 040s (including LC040 and EC040) and
>higher 68K processors.

It should be available on all 040 cpus.

>And yes, CW C/C++ (as with most good 68K
>compilers) should generate MOVE16 instructions when appropriate.

This is somewhat of a trickier issue. Since MOVE16 is not available on
cpus earlier than the 040, using the instruction will crash any Mac which
said older cpu. As such the only 'appropriate' time to generate such an
instruction is when you tell the compiler to specialize code for the 040.

The easiest way to use MOVE16 is to simply use BlockMoveData() to move your
data around. It uses the fastest general method to move data on whatever
cpu it's running on (which would be MOVE16 on 040s, other methods on earlier
cpus, and native instructions on PPC cpus).

If you have decided that BlockMoveData() is not fast enough for your taste
and are writing a specialized copy routine in assembly, please make sure
you are running on an 040 before you use MOVE16 (and provide another way to
copy if you're not). Also, I think the PPC emulator chokes on MOVE16, so
you'll want to provide a third way to copy on PPC machines, preferably
native code.

All in all, BlockMoveData() is the easiest way to go and it's pretty fast
as well. I'd strongly urge you to only hand-code assembly copy routines
if BlockMoveData() isn't fast enough. Of course, if you're simply trying
to learn assembly language, that's a different matter.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

---------------------------

>From Howard Salmon <[e-mail]>
Subject: Making sense of memory management
Date: 24 Feb 1996 22:27:04 GMT
Organization: Arizona Daily Star - AZSTARNET

I'm a beginning Mac "programmer"--I trying to teach myself about Mac
programming by slogging thru Apple's Inside Macintosh cd rom.  My method
is to try to understand one subject at a time, but since everything is
interretlated, it's slow going.  Still, I persist.

Here's a quote from the Inside Mac book on "Memory":(my questions and
comments are in parentheses):

"Master pointers for relocatable objects in your heap are always
allocated in your application heap. Because the blocks of master
pointers are nonrelocatable, it is best to allocate them as low in your
heap as possible. (Literally, how do you do this?)

You can do this by calling the MoreMasters procedure when your
application starts up." (What's that mean?  To write "MoreMasters" at
the top of your source code?)

All nuggets of knowledge welcome.  Thanks--Howard Salmon



+++++++++++++++++++++++++++

>From [e-mail] (Jerome Jahnke)
Date: Sun, 25 Feb 1996 00:01:00 GMT
Organization: BSD Academic Computing

In article <4go3bo$[e-mail]>, Howard Salmon
<[e-mail]> wrote:

> I'm a beginning Mac "programmer"--I trying to teach myself about Mac
> programming by slogging thru Apple's Inside Macintosh cd rom.  My method
> is to try to understand one subject at a time, but since everything is
> interretlated, it's slow going.  Still, I persist.

This is probably NOT the best way to do this, given it's interelatedness.
To my experience I have found that finding a project to do and then
learning what you need to know to do the project seems to work best for
me.

Then once you have the basics down (i.e. you got a working program) you go
back and scour the docs looking for ways to tweak. But to each his own.

> Here's a quote from the Inside Mac book on "Memory":(my questions and
> comments are in parentheses):
>
> "Master pointers for relocatable objects in your heap are always
> allocated in your application heap. Because the blocks of master
> pointers are nonrelocatable, it is best to allocate them as low in your
> heap as possible. (Literally, how do you do this?)

You do this by calling MoreMasters a mess of times first off. How many
times do you call MoreMasters?? Well this one is a bit more difficult to
say. I gauge it by running the great tool ZoneRanger and watching what my
heap is up to. If all of a sudden I get a bunch of non relocateable blocks
in the middle of my heap I know I need to add at least one more call of
MoreMasters to my app. You don't really have to call it, if you are
dealing with tiny handles and such islands in your heap are not a big
issue. But if you need huge contigious spaces say for big bitmaps and
such. Then MoreMasters becomes and important toolbox call.

> You can do this by calling the MoreMasters procedure when your
> application starts up." (What's that mean?  To write "MoreMasters" at
> the top of your source code?)

Best place is in your main function. Set stuff up and before you program
gets seroius about running call MoreMasters as many times as you need it.
It helps to prevent against islands forming in your heap which might make
it impossible for you to open big objects.

Jer,

--
Jerome Jahnke
BSD Academic Computing
University of Chicago
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MuffinHead)
Date: Sun, 25 Feb 1996 14:03:01 -0600
Organization: Armpit Studios VIII

In article <4go3bo$[e-mail]>, Howard Salmon
<[e-mail]> wrote:

>You can do this by calling the MoreMasters procedure when your
>application starts up." (What's that mean?  To write "MoreMasters" at
>the top of your source code?)

   Yes. A common thing to do is to call MoreMasters a few times after
you've inited all the toolbox stuff. Small apps can make do with 1 or 2
calls to MoreMasters. Larger apps might need more. The point of calling
this early is to get the master pointers allocated early (and low in the
heap) before you start loading in all sorts of other blocks.
   Use ZoneRanger to watch the block in memory. If you're using
CodeWarrior, it's on the CD. Otherwise look around the usual archive sites
for it. Step through your program and watch how pointers and handles move
around (or don't move in the case of pointers). When you start seeing lots
of non-relocatable blocks strung out haphazardly in the heap, this is
what's known as heap fragmentation. It's something you should avoid if you
can. ZoneRanger is a great tool for this.

MuffinHead
Drummer, Mac geek                                  Armpit Studios VIII
http://www.winternet.com/~muff/                    Plymouth, MN
______________________________________________________________________
Goober says "hey".                      Gomer says "hey".
  --Gomer Pyle                            --Goober Pyle

+++++++++++++++++++++++++++

>From [e-mail] (David B. Zwiefelhofer)
Date: Wed, 28 Feb 1996 08:06:19 -0500
Organization: Utility Reduction Specialists, Inc.

> "Master pointers for relocatable objects in your heap are always
> allocated in your application heap. Because the blocks of master
> pointers are nonrelocatable, it is best to allocate them as low in your
> heap as possible. (Literally, how do you do this?)

Call MoreMasters very early in your application's initialization
procedure. The point is, you want to call it before you start allocating
handles so that you don't end up fragmenting memory.

If you don't call it enough times (I think it allocates 64 master
pointers) the memory manager will call it for you, probably fragmenting
your heap. Call it early and call it often (well, often enough to cover
your needs). You should figure out the maximum number of handles your app
might need and call MoreMasters as many times as is required (i.e. twice
if you have more than 64, but less than 129 handles).

>
> You can do this by calling the MoreMasters procedure when your
> application starts up." (What's that mean?  To write "MoreMasters" at
> the top of your source code?)

Yes, like this:

MoreMasters; {Pascal}

or, I think, in C:

MoreMasters(); {C}

Good luck,

Dave

--
David B. Zwiefelhofer
Utility Reduction Specialists, Inc.
1605 Monroe Street, Suite 110
Madison, WI  53211-2052
[phone]
[phone] FAX

---------------------------

>From [e-mail] (Matthew Moss)
Subject: More than 255 chars with GetDialogItemText() ???
Date: 27 Feb 1996 13:55:26 -0600
Organization: Motorola, Inc. -- Austin,TX

Forgive me if I'm missing something obvious...

I have a dialog with a text edit field and need to retrieve its contents.
Using GetDialogItemText() will only fill a Str255... what call or set of
calls can I use to get everything typed into that field?

Thanx...

--
Matthew D Moss                                         RISC Software, Motorola
[e-mail]                              http://www.mot.com/PowerPC/

+++++++++++++++++++++++++++

>From [e-mail] (Rick Holzgrafe)
Date: Thu, 29 Feb 1996 12:01:31 -0800
Organization: Semicolon Software

In article <[e-mail]>, [e-mail] (Matthew
Moss) wrote:

> I have a dialog with a text edit field and need to retrieve its contents.
> Using GetDialogItemText() will only fill a Str255... what call or set of
> calls can I use to get everything typed into that field?

I'm not sure that such calls exist. There may be a skanky hack somewhere,
but there's a better way.

If you have a field that large to be filled in, you probably shouldn't be
using the Dialog Manager to present its window. The Dialog Manager is
meant to be used only for smallish, uncomplicated windows. Its use for
anything else is deprecated because its interface gets clumsy (as you've
found) and it is slow and inflexible.

It's not that hard to roll your own window with a few text fields and
buttons in it, and manage it in your main event loop. That way you have
full control, including full access to the text in your fields. It may
sound like more work than you want to do, but it really is a better
solution -- and it's probably less work than a skanky hack to get at the
full text in your dialog field.

I know this wasn't the answer you were hoping for, but I hope it helps anyway.

-- Rick Holzgrafe
   Semicolon Software
   [e-mail]
   http://www.opendoor.com/Rick/Semicolon.html

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Mon, 04 Mar 1996 09:11:10 -0500
Organization: Groupimage, inc.

In article <[e-mail]>, [e-mail] (Matthew
Moss) wrote:

> Forgive me if I'm missing something obvious...
>
> I have a dialog with a text edit field and need to retrieve its contents.
> Using GetDialogItemText() will only fill a Str255... what call or set of
> calls can I use to get everything typed into that field?
>
> Thanx...
>

GetDialogItem() returns a handle as part of it's arguments.  If this
dialog item is either of

    editText
    editText + itemDisable
    statText
    statText + itemDisable

then the itemHandle returned will be a handle to the text data (no length
byte, and no null at the end--the handle's size fits the characters
only).  In pseudo-code, here's what you do:

    GetDialogItem(..., &itemHandle, ...)
    get handle state
    lock handle
    var stringSize is GetHandleSize of itemHandle
    copy *itemHandle into myBuffer using stringSize
    set byte stringSize of myBuffer to zero
    reset handle state

At this point, myBuffer contains a C string.

Basically, this returned itemHandle is a TERec.hText field.  The dialog
manager swaps this hText field for editText items when the insertion point
moves from one edit box to another (the dialog manager uses a single
TEHandle per dialog box, regardless of how many editable items you have).

MGL

--
Martin-Gilles Lavoie

[CYRNFR QB ABG ZVK BE BGUREJVFR NYGRE GUR OVGF VA GUVF ZRFFNTR.]

---------------------------

>From [e-mail] (Tim DeBenedictis)
Subject: Multitasking w- WaitNextEvent()???
Date: Thu, 22 Feb 1996 20:49:15 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Howdy y'all!

I'm trying to implement a multitasking-friendly progress bar to use
during long operations (e.g. copying 60 MB files, etc.) which take place
outside of my main event loop.

To use this progress bar, one needs to periodically call my
GUpdateProgressDialog() function while performing the long drawn-out
operation.  My GUpdateProgressBar() function calls WaitNextEvent(), but
does not actually remove the event from the message queue or process it
at all:

WaitNextEvent ( 0, &event, 0, NULL );

So far, this seems to work OK: while the program is doing its 60-MB copy,
I can definitely switch to other apps (like NCSA telnet, which I am using
now) and "do stuff" in them.

However, it's not buttery-smooth as I'd like it to be.  If I switch out
of my program, then switch back into it, it's very difficult to switch
out again; I pretty much have to jam down the mouse button on the desktop
until I get control again.

I can think of several possibilities for this:

1) I am only making one call to WaitNextEvent() from within my function;
perhaps I should repeatedly call it until all non-NULL events have been
removed?

2) I am giving WaitNextEvent a zero sleep-time, allowing only minimal
time for processing background tasks.  I tried bumping this up to 10, and
while that didn't make much difference in ease of switching back and
forth to other apps, it did tremendously lengthen the total amount of
time needed for the operation (there's now a 1/6-sec pause on every
WaitNextEvent() call!)

Does anybody have any other suggestions?  Other people must have tried
this before, and I know it's possible: switching between apps while ZTerm
or Netscape is downloading is instant and seamless.

In general, what's the best way to make an application
background-task-friendly when it's going to be executing outside of its
main event loop for a long time?

-Tim DeBenedictis
[e-mail]




+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Thu, 22 Feb 1996 21:36:45 -0800
Organization: Oracle Corporation

In article <[e-mail]>, [e-mail] (Tim
DeBenedictis) wrote:

> Howdy y'all!
>
> I'm trying to implement a multitasking-friendly progress bar to use
> during long operations (e.g. copying 60 MB files, etc.) which take place
> outside of my main event loop.
>
> To use this progress bar, one needs to periodically call my
> GUpdateProgressDialog() function while performing the long drawn-out
> operation.  My GUpdateProgressBar() function calls WaitNextEvent(), but
> does not actually remove the event from the message queue or process it
> at all:
>
> WaitNextEvent ( 0, &event, 0, NULL );
[Text deleted]
> Does anybody have any other suggestions?  Other people must have tried
> this before, and I know it's possible: switching between apps while ZTerm
> or Netscape is downloading is instant and seamless.
>
> In general, what's the best way to make an application
> background-task-friendly when it's going to be executing outside of its
> main event loop for a long time?

Without touching on the issue of the sleep parameter, you need
to handle update events.  If a foreground application doesn't
handle its update events, background applications get no time.
The essential events to handle while busy-waiting in most programs are
update, suspend/resume, and activate.

-- Adam Winer
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bob Clay)
Date: Sun, 25 Feb 1996 13:23:09 -0600
Organization: INS Info Services, Des Moines, Iowa, USA


>
> In general, what's the best way to make an application
> background-task-friendly when it's going to be executing outside of its
> main event loop for a long time?
>
> -Tim DeBenedictis
> [e-mail]

Tim,

IM definitely advises against doing extensive background processing, as
this bogs down the whole concept of cooperative multitasking. When done
correctly, the background process should, indeed, take longer. When you
receive a null event in the background, quickly do the minimum that you
can do and get out.

Very cpu intensive tasks that would suffer greatly in background execution
should be implemented via a modal dialog progress box, that way the
process has the cpu all to itself.

I know many people might disagree with what I'm saying here, but this is
the correct way to do CMT on the Macintosh, as stated by Apple in IM. If
you really stop to think about it, this approach makes a lot of sense.

When we get PMT on the Macintosh, things will change quite a bit. Until
then, I feel we should stick to the approved methods for cooperative
multitasking.
This is not a criticism of your technique, Tim, but of the whole concept
of hogging the processor while in the background.

Regards,

Bob Clay

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Mon, 26 Feb 1996 11:58:07 +1300
Organization: HyperMedia Unit, Comp Sci, Auckland University

In article <[e-mail]>, [e-mail] (Tim
DeBenedictis) wrote:

>Howdy y'all!
>
>I'm trying to implement a multitasking-friendly progress bar to use
>during long operations (e.g. copying 60 MB files, etc.) which take place
>outside of my main event loop.
>
>To use this progress bar, one needs to periodically call my
>GUpdateProgressDialog() function while performing the long drawn-out
>operation.  My GUpdateProgressBar() function calls WaitNextEvent(), but
>does not actually remove the event from the message queue or process it
>at all:
>
>WaitNextEvent ( 0, &event, 0, NULL );

WaitnextEvent *does* remove the event from the event queue.

Are you doing the I/O asynchronously? This is possibly the best way to
improve the responsiveness of the machine as the user interface is not
tied to the "long  operation" (ie the 60 MB copy). Doing async reads and
writes may help the speed too if they are on different devices and thus
overlapped (particularly if one or both are network based services).
You'll need to set up multiple buffers for the concurrent I/O and I'd look
at sheduling reads and writes from ioCompletion routines if possible. This
way you can set the WNE sleep time to a large value and still have a
responsive user interface and fast copy.

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x5602
Fax:      [phone]                         Async, Therefore I Am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Yan Lee)
Date: 26 Feb 1996 01:22:37 GMT
Organization: Boston University

Bob Clay ([e-mail]) wrote:
: Tim,

: IM definitely advises against doing extensive background processing, as
: this bogs down the whole concept of cooperative multitasking. When done
: correctly, the background process should, indeed, take longer. When you
: receive a null event in the background, quickly do the minimum that you
: can do and get out.

: Very cpu intensive tasks that would suffer greatly in background execution
: should be implemented via a modal dialog progress box, that way the
: process has the cpu all to itself.

: I know many people might disagree with what I'm saying here, but this is
: the correct way to do CMT on the Macintosh, as stated by Apple in IM. If
: you really stop to think about it, this approach makes a lot of sense.

: When we get PMT on the Macintosh, things will change quite a bit. Until
: then, I feel we should stick to the approved methods for cooperative
: multitasking.
: This is not a criticism of your technique, Tim, but of the whole concept
: of hogging the processor while in the background.

: Regards,

: Bob Clay

Does Thread Manager gives any solutions to this?  Is WNE the only way to
allow background processing?  What if I was trying to make a not-so-cpu
intensive game that probably takes a fraction of the cpu time?  Well, I
guess WNE would solve the problem, but I do wonder whether the thread
manager can do some stuff too.

Tony


+++++++++++++++++++++++++++

>From [e-mail] (Bob Clay)
Date: Tue, 27 Feb 1996 01:22:18 -0600
Organization: INS Info Services, Des Moines, Iowa, USA


> Does Thread Manager gives any solutions to this?  Is WNE the only way to
> allow background processing?  What if I was trying to make a not-so-cpu
> intensive game that probably takes a fraction of the cpu time?  Well, I
> guess WNE would solve the problem, but I do wonder whether the thread
> manager can do some stuff too.
>
> Tony

I sure wish I could answer that question, but I am as unfamiliar with
Thread Manager as anybody. Perhaps someone could throw some light on the
subject?

Bob Clay

+++++++++++++++++++++++++++

>From [e-mail] (insert amusing pseudonym here)
Date: Fri, 01 Mar 1996 07:27:25 GMT
Organization: Pomona College

In article <[e-mail]>, [e-mail] (Bob Clay) writes:
>
>>
>> In general, what's the best way to make an application
>> background-task-friendly when it's going to be executing outside of its
>> main event loop for a long time?
>>
>> -Tim DeBenedictis
>> [e-mail]
>
>Tim,
>
>IM definitely advises against doing extensive background processing, as
>this bogs down the whole concept of cooperative multitasking. When done
>correctly, the background process should, indeed, take longer. When you
>receive a null event in the background, quickly do the minimum that you
>can do and get out.

[snip]

>When we get PMT on the Macintosh, things will change quite a bit. Until
>then, I feel we should stick to the approved methods for cooperative
>multitasking.
>This is not a criticism of your technique, Tim, but of the whole concept
>of hogging the processor while in the background.

I think Tim was asking how _not_ to hog the processor. (Though it's not clear
whether he means while his app is in the foreground or in the background.)

Either way, is there any reason why you shouldn't just sprinkle any code that
takes execution away from your main event loop with SystemTask calls. (Do I
have that trap name right?  I don't have a copy of IM handy, so I'm not sure.
I'm thinking of that thing you were supposed to call along with GetNextEvent
back in the days when there was no such thing as WaitNextEvent.)  That's what
_I_ would do, but I'm a newbie to mac programming, and if I'm misguided, I
would appreciate it if someone would explain the correct way to handle this!

(Actually, I think I would try to set up my app so that one way or another it
made it back the main even loop regularly, no matter what it was doing -- but I
can see that there are some places where that might not be possible.)

-jason

(please respond by email, since I don't visit this group often enough to catch
everything.)

(No, I don't have a cute .sig file.  And I NEVER use smileys.)

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 28 Feb 1996 15:10:54 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Chris Burns) wrote:

 > >WaitNextEvent ( 0, &event, 0, NULL );
 >
 > WaitnextEvent *does* remove the event from the event queue.

Not when you pass 0 for the event mask. :-)

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 28 Feb 1996 15:18:13 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Tim DeBenedictis) wrote:

 > WaitNextEvent ( 0, &event, 0, NULL );
 >
 > However, it's not buttery-smooth as I'd like it to be.  If I switch out
 > of my program, then switch back into it, it's very difficult to switch
 > out again; I pretty much have to jam down the mouse button on the desktop
 > until I get control again.

My first guess is that your application is not servicing update evnts.
Your call to WaitNextEvent is not allowing them through. If you don't
service updates, things get sluggish all over. Check out:

   <URL:http://dev.info.apple.com/technotes/Archive/Toolbox/tb_37.html>

 > 1) I am only making one call to WaitNextEvent() from within my function;
 > perhaps I should repeatedly call it until all non-NULL events have been
 > removed?

If you're updating your windows, null events should be the only other kind
you receive.

 > 2) I am giving WaitNextEvent a zero sleep-time...

That would explain sluggish background processing, but not lack of
responsiveness in your app.

 > Does anybody have any other suggestions?  Other people must have tried
 > this before, and I know it's possible: switching between apps while ZTerm
 > or Netscape is downloading is instant and seamless.

The suggestions about asynchronous i/o made by another poster were on the
right track, though I must confess I didn't read past the word
"asynchronous". :-)

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 28 Feb 1996 15:24:23 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Bob Clay) wrote:

 > > Does Thread Manager gives any solutions to this?  Is WNE the only way to
 > > allow background processing?  What if I was trying to make a not-so-cpu
 > > intensive game that probably takes a fraction of the cpu time?  Well, I
 > > guess WNE would solve the problem, but I do wonder whether the thread
 > > manager can do some stuff too.
 >
 > I sure wish I could answer that question, but I am as unfamiliar with
 > Thread Manager as anybody. Perhaps someone could throw some light on the
 > subject?

Writing multi-threaded code is not necessarily simple, but the Thread
Manager API is simple enough. Basically you write a function which becomes
a new entry point into your application and pass the function's address to
the Thread Manager. Your main event loop should call YieldToAnyThread, and
the function you passed to the Thread Manager will be called. It, in turn,
should also call YieldToAnyThread periodically, and you're off and
running.

Thread Manager, paired with asynchronous i/o, can be a big performance
win. A thread can kick off an asynchronous call and put itself to sleep.
When the asynchronous call completes, the completion routine wakes up the
thread and the thread continues on its merry way. This means all sorts of
different i/o operations can be going on at once.

In the case of a file copy of a 600M file, another issue is probably also
the size of the chunks being read and written. At some point or another,
the machine has to go read off the disk, whether the call was asynchronous
or not. Reading big chunks can reduce responsiveness on many (slightly
older) Macs.

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Dennis C. O'Brien)
Subject: Program to Program Communication (PPCInform, PPCStart)
Date: 3 Mar 1996 16:51:58 -0800
Organization: Seattle University, Seattle, WA, USA

Can anyone point me to some good (or even not so good) examples of using
the program-to-program communication routines PPCInform, PPCStart, PPCRead,
etc..  All I am trying to do at this point is to get one program to connect
to another and pass character strings between them.  I have looked all
through the MacTech CD, the csmp archive that comes with CW7 and scanned
through the IM/IAC manual.  I see a lot of definitions of the routines
themselves but could really use an example to see how they work together.

TIA

Dennis

+++++++++++++++++++++++++++

>From [e-mail] (C.K. Haun)
Date: Tue, 05 Mar 1996 04:56:39 -0700
Organization: Ravenware Software

> > Can anyone point me to some good (or even not so good) examples of using
> >the program-to-program communication routines PPCInform, PPCStart,
> PPCRead,
> > etc..

The sample NonAppAppleEvents on the developer CD (and various mirrors)
uses PPC to pass data around, the two files AEDeamonPPCStuff.c and
AECDEV.PPC.c show how a control panel and a background-only app use PPC to
communicate.
C.K. Haun
Ravenware Software
[e-mail]
                          The Mild Bunch
1996 Royal Star 1300      1991 Voyager 1200       1990 Virago 750
1993 Virago 535           1987 Reflex 225         <rent this space>

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 4 Mar 1996 00:24:59 -0500
Organization: America Online, Inc. (1-800-827-6364)

Dennis C. O'Brien wrote:
>Can anyone point me to some good (or even not so good) examples
>of using the program-to-program communication routines
>PPCInform, PPCStart, PPCRead, etc..  All I am trying to do at
>this point is to get one program to connect to another and pass
>character strings between them.  I have looked all  through the
>MacTech CD, the csmp archive that comes with CW7 and scanned
>through the IM/IAC manual.  I see a lot of definitions of the
>routines themselves but could really use an example to see how
>they work together.

Server Remote Control uses the PPC Toolbox for communications between the
client application and the server application. You can download Server
Remote Control with its source code from Apple's ftp server at
<ftp://sam.austin.apple.com/Apple.Support.Area/Developer_Services/Tool_Che
st/Interapplication_Communication/Server_Remote_Control_1.1/Server_Remote_C
ontrol_1.1.sit.hqx>.

I also wrote a very simple PPC Toolbox sample before I left Apple DTS last
summer. I looked for it on the Developer CD, but it's not there, so I just
uploaded it to my ftp directory and you can get it there at
<ftp://members.aol.com/JumpLong/PPCToolbox_Samples.sit.hqx>. I'll have to
make sure it gets on the Dev CD and Apple's ftp server in the future.

- Jim Luther

---------------------------

>From [e-mail] (Sean McBride)
Subject: Q: The OSErr type, and unreserved values....
Date: Sun, 03 Mar 1996 18:12:18 -0500
Organization: Communications Accessibles Montreal, Quebec Canada

I'm looking for a way for my functions to return errors nicely... If
during the course of excution a MacOS function returns an OSErr then I
return that, but if something goes wrong that isn't ToolBox related I
don't want to pass back an OSErr for fear of using a value that already
represents an error...

My question is: are there any values (OSErr) that are free to be used by
the programmer?  Values that are set aside and guarenteed not to be
returned by a ToolBox call?

Any help is appreciated, thanks...

_______________________________________________________________________
  H H      |                   |                                      |
  | |      | Sean McBride      |                                      |
H-C-C-O-H  | [e-mail]   |       0010 1001 1010                 |
  | |      | Montreal, Canada  |                                      |
  H H      |                   |                                      |
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 4 Mar 1996 00:09:39 -0500
Organization: America Online, Inc. (1-800-827-6364)

Sean McBride wrote:
>I'm looking for a way for my functions to return errors
>nicely... If during the course of excution a MacOS function
>returns an OSErr then I return that, but if something goes wrong
>that isn't ToolBox related I don't want to pass back an OSErr
>for fear of using a value that already represents an error...
>
>My question is: are there any values (OSErr) that are free to be
>used by the programmer?  Values that are set aside and
>guarenteed not to be returned by a ToolBox call?

Some people use positive values since they are used by the Macintosh OS
for fatal (SysError) errors. Since the system won't be returning from
those :), they are fairly safe to use inside your code. Just don't display
your internal errors in an error dialog - use a descriptive error message
instead.

Me... I usually just find a defined error code whose meaning fits (or is
close to) the problem found.

- Jim Luther

+++++++++++++++++++++++++++

>From Symantec/Scott Morison <[e-mail]>
Date: Tue, 05 Mar 1996 09:14:16 +0000
Organization: Symantec Corporation

Sean McBride wrote:
> My question is: are there any values (OSErr) that are free to be used by
> the programmer?  Values that are set aside and guarenteed not to be
> returned by a ToolBox call?


As long as you choose a value outside of Apple's range, you're ok...;-)

Apple has reserved a range of OSErr values for their own use. This range happens to
be -32768 to 32767; i.e., the entire range of the OSErr type. Not much room left for
outsiders.

A couple of suggestions:

* Avoid negative values (-32768 to -1); Apple's got them pretty well tied up.

* Positive Error codes between 1000 and 19000 seem to be fairly scarce, but there's
still no guarantee you won't bump heads, and moreover you need to be certain that
whatever it is your error values are passed to doesn't just check for failure on
negative values, as some OS functions do.

** Instead of using OSErr as your return type, use a long. Three reasons:
  1) You'll have values outside of the magic Apple reserved range;
  2) on the PPC, longs are more efficient and in general require fewer instructions
to process;
  3) you'll still be able to receive error codes in the OSErr range without any type
conversion fuss.

There's my 32 bits.

Scott Morison, Symantec Development Tools Technical Support tofu boy
.
- -----------------------------------------------------
For further information on this or any other C/C++/Pascal/Java issue, please feel
free to write to Symantec's online Development Tools tech support zen masters:
[e-mail],
or give us a ring at : 541/465-8470

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Tieskoetter)
Date: 6 Mar 1996 20:35:27 GMT
Organization: Albatross Productions

In article <[e-mail]>
Symantec/Scott Morison <[e-mail]> writes:

> ** Instead of using OSErr as your return type, use a long. Three reasons:
>   1) You'll have values outside of the magic Apple reserved range;
>   2) on the PPC, longs are more efficient and in general require fewer instructions
> to process;
>   3) you'll still be able to receive error codes in the OSErr range without any type
> conversion fuss.


But be careful that nowhere in the calling chain does your long error
get converted to an OSErr - your carefully-protected error will
suddenly disappear.

-kevin

--
//----------------------------------------------------------------------

  Kevin Tieskoetter, Software Prestidigitator, Specular International
//----------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 05 Mar 1996 11:39:38 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Sean McBride) wrote:

 > I'm looking for a way for my functions to return errors nicely... If
 > during the course of excution a MacOS function returns an OSErr then I
 > return that, but if something goes wrong that isn't ToolBox related I
 > don't want to pass back an OSErr for fear of using a value that already
 > represents an error...
 >
 > My question is: are there any values (OSErr) that are free to be used by
 > the programmer?  Values that are set aside and guarenteed not to be
 > returned by a ToolBox call?

Sadly, no. What I do is define an error type which potentially has
information in addition to the 16-bit OSErr. The other information tells
me whether I'm dealing with an OSErr or something else like an internal
error. You can do this nicely with a simple 32-bit integer (long or
unsigned long) and bit-level operators. Write some macros or inline
functions to make it easy to construct these codes. For example:

    #define kErrType_OS         0x00010000
    #define kErrType_Internal   0x00020000

    #define MakeOSErr(x)        ((x) | kErrType_OS)
    #define MakeInternalErr(x)  ((x) | kErrType_Internal)

    #define CheckForError(x) (!!((x) & 0x0000FFFF))

    typedef unsigned long tErr;

    #ifndef __FILES__
    #   include <Files.h>
    #endif

    static tErr FSpGetFInfo_Glue (const FSSpec *fssP, FInfo *fi)
    {
        MakeOSErr (FSpGetFInfo (fssP,fi));
    }

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

---------------------------

>From [e-mail] (Vince Tourangeau)
Subject: QD3D and Textures...
Date: 26 Feb 1996 05:10:07 GMT
Organization: Carleton University, Ottawa, Canada


I'm still trying to figure out how one orients a texture onto a surface in
QD3D/3DMF. For example, if I was writing my own software and was wrapping
a texture onto a sphere, I might use spherical polar coordinates. However,
there's no explicit code in QD3D (so far as I can tell, anyways) for doing
this. So how would such a texture be properly mapped onto a sphere using
QD3D? More generally, how is a texture mapped onto/oriented to an object?
Thanks,
    Vince


- --------------------------------------------------------------------
Vince Tourangeau
[e-mail]

Did you hear about the dyslexic, agnostic insomniac?
She stays awake at night, wondering if there's a dog.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Chao-Kuang Yang)
Date: Mon, 26 Feb 96 10:05:57 GMT
Organization: Cram Softnology

There is no such a geometry as sphere in QD3D.  You will have to use trigrids
to form a sphere.  Thus, you can assign each vertex in trigrid a texture
coordinates.  Basically, that's how it is done.  If you are reading the sphere
from a 3DMF file, you will have assign each vertex in the file a texture
coordinate.  This is painful but I believe that it is the only way to do it.

In fact, if the sphere has a texture assigned to it in 3DMF, after you read
the sphere in, it should still have the save texture after you rendered it.
Just don't forget to submit the texture shader.  Otherwise, you won't see
textures at all.

Mark Yang

In article <4grfbf$[e-mail]>, [e-mail]
(Vince Tourangeau) wrote:
>
>I'm still trying to figure out how one orients a texture onto a surface in
>QD3D/3DMF. For example, if I was writing my own software and was wrapping
>a texture onto a sphere, I might use spherical polar coordinates. However,
>there's no explicit code in QD3D (so far as I can tell, anyways) for doing
>this. So how would such a texture be properly mapped onto a sphere using
>QD3D? More generally, how is a texture mapped onto/oriented to an object?
>Thanks,
>        Vince
>
>
>----------------------------------------------------------------------
>Vince Tourangeau
>[e-mail]
>
>Did you hear about the dyslexic, agnostic insomniac?
>She stays awake at night, wondering if there's a dog.

- ---------------------------------------------------------------------------
email:  [e-mail]
        [e-mail]

Home Page: http://asm1.usc.edu/ckyang.html

+++++++++++++++++++++++++++

>From [e-mail] (Vince Tourangeau)
Date: 27 Feb 1996 03:40:24 GMT
Organization: Carleton University, Ottawa, Canada

Okay, but how do I line up the texture/make sure the texture's oriented on
an object? ie, How do those UV things work?
    Vince



- --------------------------------------------------------------------
Vince Tourangeau
[e-mail]

Did you hear about the dyslexic, agnostic insomniac?
She stays awake at night, wondering if there's a dog.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Chao-Kuang Yang)
Date: Tue, 27 Feb 96 08:32:58 GMT
Organization: Cram Softnology

It is not that hard, but it is hard to explain UV coordinate in email.  You
can refer to QD3D references or books for it.

Basically, each point has its own UV coordinate.  The range of UV coordinate
is 0 (zero) to 1.  They correspond to the texuture map space.

i.e. If you have a picture which has 640x480 in size, UV (0,0.5) = 0,240.
Thus, at vertex which has UV (0,0.5) would have the color at 0,240 in the
picture.

See, it's kind of fuzzy if you see the explaination above.  The best way is to
 check out QD3D references or any computer graphics book about texture
mapping.

Mark Yang

In article <4gtuf8$[e-mail]>, [e-mail]
(Vince Tourangeau) wrote:
>Okay, but how do I line up the texture/make sure the texture's oriented on
>an object? ie, How do those UV things work?
>        Vince
>
>
>
>----------------------------------------------------------------------
>Vince Tourangeau
>[e-mail]
>
>Did you hear about the dyslexic, agnostic insomniac?
>She stays awake at night, wondering if there's a dog.

- ---------------------------------------------------------------------------
email:  [e-mail]
        [e-mail]

Home Page: http://asm1.usc.edu/ckyang.html

+++++++++++++++++++++++++++

>From [e-mail] (Eric Jackson)
Date: Wed, 28 Feb 1996 17:15:43 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <4grfbf$[e-mail]>,
Vince Tourangeau <[e-mail]> wrote:
>
>I'm still trying to figure out how one orients a texture onto a surface in
>QD3D/3DMF. For example, if I was writing my own software and was wrapping
>a texture onto a sphere, I might use spherical polar coordinates. However,
>there's no explicit code in QD3D (so far as I can tell, anyways) for doing
>this. So how would such a texture be properly mapped onto a sphere using
>QD3D? More generally, how is a texture mapped onto/oriented to an object?
>Thanks,
>    Vince
>
>
>----------------------------------------------------------------------
>Vince Tourangeau
>[e-mail]
>
>Did you hear about the dyslexic, agnostic insomniac?
>She stays awake at night, wondering if there's a dog.

Well Vince I find that knothing says it better than an example so here you go
I am pasting this in from my code so sorry if the line breaks don't all work
out just perfectly but good luck with it anyway.

void MainView::ParameteriseParallelTrig(long NumberOfRows,
                                   long NumberOfColumns){

//This function is called to reparameterise our trigrid
//after it has been incorrectly parameterized to cancel out
//the effects of perspective

    float    FloatNumberOfRows,FloatNumberOfColumns;
    short    j,k;
    TQ3Param2D            param2D;

    FloatNumberOfRows     = NumberOfRows;
    FloatNumberOfColumns = NumberOfColumns;

    TQ3AttributeSet        UVParamaterAttribute;

    for (j=0;j<NumberOfRows;j++)
        {
        //NumberRows of course is an input parameter to this function

            FloatNumberOfColumns = NumberOfColumns;


            for (k=0;k<NumberOfColumns;k++)
            {
            param2D.u =2*(NumberOfColumns - k)/FloatNumberOfColumns;
            param2D.v =-2*(NumberOfRows - j)/FloatNumberOfRows;

            //The v values move forewards and backwards

            UVParamaterAttribute = Q3AttributeSet_New();

            //Q3AttributeSet_Add(TriGridData->vertices[(j*NumberOfColumns)+k].attributeSet,
            //                kQ3AttributeTypeShadingUV, ¶m2D);

            Q3AttributeSet_Add(UVParamaterAttribute,
                            kQ3AttributeTypeShadingUV, ¶m2D);


            if (this->fTriGrid)
            Q3TriGrid_SetVertexAttributeSet(this->fTriGrid,j,k,UVParamaterAttribute);

            Q3Object_Dispose(UVParamaterAttribute);

            }
        }
}


Good luck

Eric Jackson
[e-mail]


---------------------------

>From [e-mail] (Ram Rajadhyaksha)
Subject: System 7 PopUp CDEF Shares MenuHandles?
Date: Tue, 05 Mar 1996 21:48:18 -0500
Organization: The Ohio State University

Hey, I have an application that has various pop-ups in each of it's
windows. As I found out when I have multiple documents open that if I
delete an item from a pop-up control in one window- the result also shows
up in every OTHER window that has the same control! Do all the controls
share the same MenuHandle? (This would really suck) Looking at the mHandle
field in the PopUpPrivateHandle of all the different controls shows the
same address.

Am I doing something wrong? I'm creating them with NewControl() and
specifying the same resource ID for the menu.

If I'm not doing something wrong, then would creating the control with a
"dummy" menu resource, deleting that menuHandle, creating a new menu
handle for each control work?

Weird...

--Ram

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Wed, 6 Mar 1996 12:36:05 GMT
Organization: Apple Computer, Inc.

In article
<[e-mail]>,
[e-mail] (Ram Rajadhyaksha) wrote:

> Hey, I have an application that has various pop-ups in each of it's
> windows. As I found out when I have multiple documents open that if I
> delete an item from a pop-up control in one window- the result also shows
> up in every OTHER window that has the same control! Do all the controls
> share the same MenuHandle? (This would really suck) Looking at the mHandle
> field in the PopUpPrivateHandle of all the different controls shows the
> same address.
>
> Am I doing something wrong? I'm creating them with NewControl() and
> specifying the same resource ID for the menu.
>
> If I'm not doing something wrong, then would creating the control with a
> "dummy" menu resource, deleting that menuHandle, creating a new menu
> handle for each control work?

This is kinda from memory, because it's been a long time since
I had to fix this bug.

The Pop Up Control adds the menu for you, if it is not already in the
menu bar.  It then removes this menu from the menu bar if it needed
to install it, when the control is deleted.

So, the best way to do this is to simply add the menu to the menu
bar yourself before the first doc, and delete it after the last one.
Optionally, you can just add it once at the begining of your
application.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

---------------------------

>From Anders Wahlin <[e-mail]>
Subject: Where can I get a CustomGetFolder that works?
Date: Mon, 4 Mar 1996 11:37:19 GMT
Organization: Gothenburg University

I need to have a CustomGetFolder function in my app. I have one now which
works on all folders except for volume-folders. Are they special? So,
does anyone know where I can get a CustomGetFolder that works?

Thank you.


+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 4 Mar 1996 12:01:19 -0500
Organization: America Online, Inc. (1-800-827-6364)

Anders Wahlin wrote:
>I need to have a CustomGetFolder function in my app. I have one now
>which  works on all folders except for volume-folders. Are they special?
>So, does anyone know where I can get a CustomGetFolder that works?

You can get one I wrote from
<ftp://members.aol.com/JumpLong/MoreStandardFile.sit.hqx>. It is a sample
I started while in DTS. The C code is complete. The only part that's
incomplete  in the code is the balloon help (it still has the standard
balloon help which doesn't make complete sense and doesn't handle the
additional buttons I added to the dialog).

The archive includes both a StandardSelectVolume and a StandardGetFolder
function. The StandardGetFolder also has the added the features of:
1) optionally restricting the selected folder to visible folders.
2) optionally restricting the selected folder to folders the user has
write access to.

- Jim Luther

---------------------------

>From [e-mail] (Dale M. Greer)
Subject: Wrapping Pictures Around Closed QD3D Surfaces
Date: Thu, 29 Feb 1996 01:22:35 -0600
Organization: Studio Zero

Wrapping Pictures Around Closed QD3D Surfaces

Many thanks to Jesse Holle for giving me the clue I needed to make
pictures wrap completely around closed QD3D surfaces.  For anyone else
who encounters this problem, here it is restated with the solution.


Suppose you are creating a mesh and you want a surface that's like a
short section of pipe.  The indices of the vertices of this surface look
like this.

 0   1   2   3   4
 5   6   7   8   9

>From the top -
  the first row looks like this  -  and the second row looks like this.

              0 1                                 5 6
             4   2                               9   7
               3                                   8

You make triangular faces for the surface, where each number in each
triplet is the index of one of the vertices m

aking up the face.  For
example, the first face has indices 5,0,1, the second has 5,1,6, the
third has 6,1,2, etc.

When you get to the end, you want the last two faces to link up to the
first two vertices, to make a closed surface, so the last two faces have
indices like so - 9,4,0, and 9,0,5.

Now you want to put uv parameters on each vertex, so you can map a picture
over the entire surface.  To get a complete picture, u and v must range
from 0.0 to 1.0.  If vertices 0,1,2,3,4 have u-values of 0.0, 0.25, 0.5,
0.75, 1.0, you get the whole picture but you also get a gap where the last
two faces link up with the first two vertices.  You can't fix this by
having u-values of 0.0, 0.2, 0.4, 0.6, 0.8, 1.0, because there is no place
for the 1.0 to go.  Vertex zero needs to have two u-values of both 0.0 and
1.0, as does vertex 5.

You can't do that with QuickDraw 3D's vertex attributes, but you can do
it with corner attributes.  Each vertex can have as many corners as it
has faces connected to it.  One problem is that in order to use uv
corner attributes to map a portion of a picture onto a face, the face
must have as many corner attributes as it has vertices.  With vertex
attributes, the value at each vertex is good for all connected faces, but
with corner attributes, the value is only good for one face.  If you
use corner attributes for uv mapping, you have to use many more of them that
you would use of vertex attributes.

I solved that problem by mapping all around with vertex attributes and
then adding corner attributes for the last column of faces.  In the
above example, vertices 0,1,2,3,4 would be mapped as 0.0, 0.2, 0.4,
0.6, 0.8.  Then vertices 4 and 9 of face 9,4,0 would both get corner
attribute u-values of 0.8, with vertex 0 getting a corner attribute
u-value of 1.0.  Vertex 9 of face 9,0,5 would have a u-value of 0.8,
with vertices 0 and 5 of that face both getting u-values of 1.0.

--
Dale Greer, [e-mail]
"I'm tryin' ta think, but nutt'n happens!" - Curley

---------------------------

>From Sven Olsson <[e-mail]>
Subject: [Q] Building Popup-menus at runtime
Date: 6 Mar 1996 14:48:08 GMT
Organization: -

Hi there,
I´m having som truoble building popup menus at runtime. The following code
does the trick except that nothing shows up in the control when drawn,
You have to click on the control and select an item before the text is
displayed.

If I´ve forgotten or misunderstood something, please let me know:-)

Thanks in advance,
Per

my code:

   theControl = dataPtr->theHPDPopup;
   theMenu =(MenuHandle)GetCRefCon(theControl);

   // Build List
   hpdHandle=gNorsonic.hpdRecListHandle;

   // Make sure menu is empty before building a new
   UnBuildPopup(theMenu);

   while(hpdHandle)
   {
      ...

      AppendMenu(theMenu, (unsigned char *)buffer);
      hpdHandle=(**hpdHandle).nextHPDHandle;
   }

   hpdHandle=dataBasePtr->selectedHPDHandle;
   selected = (short)FindHPDOrderNumber(hpdHandle);
   SetControlValue(theControl, selected);



+++++++++++++++++++++++++++

>From [e-mail] (Ram Rajadhyaksha)
Date: Wed, 06 Mar 1996 10:44:56 -0500
Organization: The Ohio State University

In article <4hk8j8$[e-mail]>, Sven Olsson <[e-mail]> wrote:

>Hi there,
>I´m having som truoble building popup menus at runtime. The following code
>does the trick except that nothing shows up in the control when drawn,
>You have to click on the control and select an item before the text is
>displayed.

>   theControl = dataPtr->theHPDPopup;
>   theMenu =(MenuHandle)GetCRefCon(theControl);

Are you using the Sys. 7 CDEF? Then to get to the menuhandle, you need
to dereference the ContrlData field and cast it into a PopUpPrivDataHndl,
dereference that, and then you can get the correct mHandle.

ie:       myMenuHandle =
((**(PopupPrivateDataHandle)((**myPopUpControlHandle).contrlData)).mHandle);

--Ram

+++++++++++++++++++++++++++

>From [e-mail] (David B. Zwiefelhofer)
Date: Wed, 06 Mar 1996 10:58:17 -0500
Organization: Utility Reduction Specialists, Inc.

In article <4hk8j8$[e-mail]>, Sven Olsson <[e-mail]> wrote:

> Hi there,
> I´m having som truoble building popup menus at runtime. The following code
> does the trick except that nothing shows up in the control when drawn,
> You have to click on the control and select an item before the text is
> displayed.

[code snipped]

All you need to do beyond this is setControlMaximum so the control knows
what values it can take on. If you don't know how many items you've
appended use CountMItems and then use the result with setControlMaximum.

You might also want to use the popupPrivateData structure to access the
control's menu in a clean and easy manner. It's not clear to me how you
are currently doing it.

Good luck,

Dave

SetControlMaximum(theControl, maxValue);

The Pop-Up Menu Private Data Record Control Manager
Inside Macintosh: Macintosh Toolbox Essentials,  page 5-77.
#include <Controls.h>

You can obtain the menu handle and the menu ID of the menu associated with
a pop-up menu by dereferencing the contrlData field of the pop-up menu’s
control record. The contrlData field of a control record is a handle to a
block of private information. For pop-up menu controls, this field is a
handle to a pop-up private data record, which is a data structure of type
popupPrivateData.
TYPE  popupPrivateData =
   RECORD
      mHandle:    MenuHandle;                {handle to menu record}
      mID:        Integer;                   {menu ID}
      mPrivate:   ARRAY[0..0] OF SignedByte; {reserved}
   END;
Field Descriptions
mHandle     Contains a handle to the menu.
mID         The menu ID of the menu.
mPrivate    Reserved.
You can use the standard pop-up control definition function to manage
pop-up menus. For information on creating pop-up menus, see “Creating a
Pop-Up Menu” beginning on page 5-25 of Inside Macintosh: Macintosh Toolbox
Essentials. See the chapter “Menu Manager” in Inside Macintosh: Macintosh
Toolbox Essentials for additional information.

--
David B. Zwiefelhofer
Utility Reduction Specialists, Inc.
1605 Monroe Street, Suite 110
Madison, WI  53211-2052
[phone]
[phone] FAX

---------------------------

End of C.S.M.P. Digest
**********************